Module Intoduction

1.1 - understanding ansible

1.2 - Host requirements

1.3 - Installing ansible on the control node.

1.4 - Preparing managed nodes

1.5 - Verifying ansible installation

2.1 Setting up static inventory:

• Using Ad Hoc Commands:
  • Ad Hoc commands are used to make a quick setup just from the CLI without making it too complicated.
  • Basic structure : ansible <hosts> -m <module_name> -a ‘module_args’ -i <inventory_name>
  • example 1: ansible all -m user -a ‘name=chxmxi’
  • example 2: ansible all -m command -a ‘id chxmxi’

• Understanding Ansible Modules
  • Modules allow you to perform specific tasks on managed hosts.
  • Modules are used to tell ansible what you want it to do, either in ad-hoc commands as well as in playbooks
  • user ansible-doc -l for a list of modules currently available (You can develop your own modules)
  • ansible-doc will show which arguments are available and which are required.
  • Ansible modules are idempotent: which means that when running them again they’ll give the same result and if a task has already been configured, they won’t do it again.

• Using ansible-doc to get Module Documentation
  • The ansible-doc command provides documentation about modules
  • Use ansible-doc -l for a list of all modules
  • ansible-doc <module_name> to get the documentation for a specific module
    • Modules status :
      • Stableinterface: the module is safe to use
      • preview: the module is in tech preview and its keywords may change.
      • deprecated: the module should not be used anymore, and will be removed in a future release.
      • removed: the module has been removed and the documentation only still exists to help users migrating to its replacement.
    • Modules Support statuts:
      • core: supported by the core ansible devs
      • curated: supported by the partners and companies in the community, proposed changes are reviewed by the core devs
      • community: supported by the community.

• Introduction Essential Ansible Modules
  • ping: ansible all -m ping
  • service: checks if a service is currently running ansible all -m service -a "name=httpd state=started"
  • command: runs any command, but not through a shell. ansible all -m command -a “/sbin/reboot -t now”
  • shell: runs arbitrary commands through shell ansible all -m shell -a set ansible all -m shell -a “cat /etc/passwd”
  • raw: runs commands on a remote host without a need for py. ansible all -m raw -a “yum install python3 -y”
  • copy: copies a file to the managed host. ansible all -m copy -a ‘content=”hello” dest=/etc/file'

• Using YAML to write Playbooks
  • Ansible Playbooks are used to run multiple tasks against managed hosts in a scripted way
  • In playbooks, one or multiple plays are started
    • each plays run one or more tasks
    • Different modules are used to perform the actual work for a task

• Verifying Playbook Syntax
  • in ~/.vimrc ⇒ autocmd FileType yaml setlocal ai ts=2 sw=2 et
  • ansible-playbook —syntax-check <playbook name>
  • -v[vvv] to increase the output verbosity
  • -C to perform a dry run

• Writing Multiple-Play Playbooks

• Understanding Variables
  • A Variable is a label that is assigned to a specific value to make it easy to refer to that value throughout the playbook.
  • Variables can be defined by administrators at different levels
  • A fact is a special type of variable, that refers to a current state of an Ansible-managed system.

• Using Variables
  • Variables can be set at different levels
    • In a playbook - hosts: all vars: web_package: httpd
    • In inventory (deprecated)
    • In inclusion files - hosts: all vars_files: - vars/<filename>.yml
  • Variables names :
    • The name must start with a letter
    • Variable name can only contain letters, numbers, and “_”.

• Understanding Variable Precedence
  • Vars can be set with different types of scope
    • Global scope: var is set from inventory or the cli ansible-playbook site.yml -e “web_package=apache”
    • Play scope: var is set from a play
    • Host scope: var is set in inventory or using host variable inclusion file

• Managing Host Variables
  • Vars can be assigned to hosts and to groups of hosts
  • Use directories to populate host and group variables
  • host vars can be stored in your project dir:
    • /host_vars/<host name>
    • /group_vars/<group name>
  • You don’t have to define vars in these dirs in the playbook as they are picked automatically

• Using Multi-valued Variables
  • Multi-valued variable, it can be written as an array(list) or as a dictionary(hash) and this depends on the use-case.
  • Using Dictionary :
    • Dictionaries can be written in two ways : One ⇒ users: linda: username: linda shell: /bin/bash lisa: username: lisa shell: /bin/sh Two ⇒ users: linda: {username: ’linda’, shell: ’/bin/bash’} lisa: {username: ‘lisa’, shell: ‘/bin/sh’}
    • To address items in a dictionary, you can use two notations :
      • var_name[’key’] ⇒ users[’linda’][’shell’]
      • var_name.key ⇒ users.linda.shell
    • You can’t use loop or with_items on dictionaries
  • Using arays :
    • Arrays provide a list of items, where each item can be addressed separately users: - username: linda shell: /binsh - username: lisa shell: /bin/sh
    • You can address to an individual item in the array using {{ var_name[0] }} notation
    • Use with_items or loop to access all variables.

• Using Ansible Vault
  • ansible vault is developed to protect sensitive data (web keys, passwords..) through encrypting and decrypting files.
  • create encrypted file ⇒ ansible-vault create playook.yml
  • You can enter the password using passwd stored in a file (Make sure to give the perms 0600) ⇒ ansible-vault create —vault-password-file=vault-pass playbook.yml
  • view a vault enrypted file ⇒ ansible-vault view playbook.yml
  • to edit ⇒ ansible-vault edit playbook.yml
  • encrypt/decrypt ⇒ ansible-vault encrypt/decrpyt playbook.yml
  • change passwd of an exisitng file ⇒ ansible-vault rekey

• Working with Facts.
  • Ansible facts are variables that are automatically set and discovered by ansible on managed hosts
  • Facts contain information about hosts that can be used in conditionals
  • By default, all playbooks perform fact-gathering before running the actual plays
  • use the setup module to run fact-gathering in an ad-hoc command.
  • use the debug module to print the value of the ansible_facts variable
  • ansible facts will show you hardware information, storage configuration and much more..
  • Use gather_facts: no in the play header to disable it as it may seriously speed up playbooks.
  • Using the setup module in a task will run a fact gathering.

• Creating Custom Facts:
  • Custom facts allow administrators to dynamically generate variables which are stored as facts
  • Custom facts are stored in an ini or JSON file in the /etc/ansible/facts.d directory on the managed host
    • The name of these files must end in .fact
  • Custom facts are stored in the ansible_facts.ansible_local variable
  • Use ansibe <hostname> -m setup -a “filter=ansible_local” to display local facts.